Scalable header extension

ABSTRACT

Systems and methods for extending header fields are disclosed. The header field may be extended without changing the current size of the header. Reserve bits may be used to indicate the use of an extended header and the extended header may be store in a variety of locations within the frame, including the frame payload or pad bits.

CLAIM OF PRIORITY UNDER 35 U.S.C. §119

The present application is a continuation of U.S. patent applicationSer. No. 12/716,041, filed Mar. 2, 2010 and entitled “SCALABLE HEADEREXTENSION,” which is hereby expressly incorporated in its entirety byreference herein, and which claims priority to U.S. Provisional Appl.No. 61/157,126, filed Mar. 3, 2009 and entitled “SCALABLE HEADEREXTENSION WITHIN PSDU,” which is hereby expressly incorporated in itsentirety by reference herein.

BACKGROUND

1. Field

The present application relates generally to wireless communication, andmore specifically to systems and methods of extending packet headers inwireless communication.

2. Background

Wireless communication systems are widely deployed to provide varioustypes of communication (e.g., voice, data, multimedia services, etc.) tomultiple users. As the demand for high-rate and multimedia data servicesrapidly grows, there lies a challenge to implement efficient and robustcommunication systems with enhanced performance.

SUMMARY

In an embodiment, a communication device for transmitting at least afirst packet in a wireless communication system is provided. The firstpacket comprises a header field, a payload field, and a padding field.The communication device comprises a memory configured to store a firstextension header. The device also comprises processor in communicationwith the memory and configured to determine if at least one bit isavailable in the first extension header for transmission. The one bit isadditional to a plurality of bits occupying the header field. The devicefurther comprises a message formatter in communication with at least oneof the processor and the memory and configured to indicate in the headerfield the presence of the first extension header, and insert at leastone portion of the first extension header in at least one of the payloadfield and the padding field of the first packet.

In another embodiment, a communication device for transmitting at leasta first packet in a wireless communication system is provided. The firstpacket comprises a header field, a payload field, and a padding field.The communication device comprises means for storing a first extensionheader. The device also comprises means for determining if at least onebit is available in the first extension header for transmission. The onebit is additional to a plurality of bits occupying the header field, andthe determining means is in communication with the storing means. Thedevice further comprises means for indicating in the header field thepresence of the first extension header and inserting at least oneportion of the first extension header in at least one of the payloadfield and the padding field of the first packet. The indicating andinserting means is in communication with the storing means or thedetermining means.

In another embodiment, a method of communicating at least a first packetin a wireless communication system is provided. The first packetcomprises a header field, a payload field, and a padding field. Themethod comprises storing a first extension header and determining if atleast one bit is available in the first extension header fortransmission. The one bit is additional to a plurality of bits occupyingthe header field. The method further comprises indicating in the headerfield of the first packet the presence of the first extension header andinserting at least one portion of the first extension header in at leastone of the payload field and the padding field of the first packet.

In another embodiment, a computer readable product, comprising at leastone computer-readable medium is provided. The computer readable productcomprises code for causing a computer to determine, at least in part, ifat least one bit is available in the first extension header fortransmission. The one bit is additional to a plurality of bits occupyingthe header field. The computer readable product also comprises code(e.g., executable instructions) for causing a computer to indicate inthe header field of the first packet the presence of the first extensionheader and insert at least one portion of the first extension header inat least one of the payload field and the padding field of the firstpacket.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A illustrates a first example wireless communication network.

FIG. 1B illustrates a second example wireless communication network.

FIG. 2 is a functional block diagram of an example wirelesscommunication device for use in the wireless communication networks ofFIG. 1A and FIG. 1B.

FIG. 3 is a functional block diagram of an example macro node for use inthe wireless communication network of FIG. 1.

FIG. 4 illustrates an example frame structure conforming to the ECMA-368standard.

FIG. 5 illustrates a physical layer bit assignment for the framestructure of FIG. 4.

FIG. 6 is an example scalable header extension structure according to anillustrative embodiment.

FIG. 7 illustrates an example modified ECMA-368 frame structure inaccordance with the scalable header extension structure of FIG. 6.

FIG. 8 is an example extended PLCP header structure according to a firstembodiment.

FIG. 9 illustrates an example coding table for the extension headerinformation field of the extended PLCP header structure of FIG. 8.

FIG. 10 is an example extended PLCP header structure according to asecond embodiment.

FIG. 11 is an example extended PLCP header structure according to athird embodiment.

FIG. 12 is a method of extending a PLCP header according to oneembodiment.

DETAILED DESCRIPTION

The word “exemplary” is used herein to mean “serving as an example,instance, or illustration.” Any embodiment described herein as“exemplary” is not necessarily to be construed as preferred oradvantageous over other embodiments. The techniques described herein maybe used for various wireless communication networks such as CodeDivision Multiple Access (CDMA) networks, Time Division Multiple Access(TDMA) networks, Frequency Division Multiple Access (FDMA) networks,Orthogonal FDMA (OFDMA) networks, Single-Carrier FDMA (SC-FDMA)networks, etc. The terms “networks” and “systems” are often usedinterchangeably. A CDMA network may implement a radio technology such asUniversal Terrestrial Radio Access (UTRA), CDMA2000, etc. UTRA includesWideband-CDMA (W-CDMA) and Low Chip Rate (LCR). CDMA2000 covers IS-2000,IS-95 and IS-856 standards. A TDMA network may implement a radiotechnology such as Global System for Mobile Communications (GSM). AnOFDMA network may implement a radio technology such as Evolved UTRA(E-UTRA), IEEE 802.11, IEEE 802.16, IEEE 802.20, Flash-OFDMA, etc. UTRA,E-UTRA, and GSM are part of Universal Mobile Telecommunication System(UMTS). Long Term Evolution (LTE) is an upcoming release of UMTS thatuses E-UTRA. UTRA, E-UTRA, GSM, UMTS and LTE are described in documentsfrom an organization named “3rd Generation Partnership Project” (3GPP).CDMA2000 is described in documents from an organization named “3rdGeneration Partnership Project 2” (3GPP2). These various radiotechnologies and standards are known in the art.

Single carrier frequency division multiple access (SC-FDMA), whichutilizes single carrier modulation and frequency domain equalization isa technique. SC-FDMA has similar performance and essentially the sameoverall complexity as those of OFDMA system. SC-FDMA signal has lowerpeak-to-average power ratio (PAPR) because of its inherent singlecarrier structure. SC-FDMA has drawn great attention, especially in theuplink communications where lower PAPR greatly benefits the mobileterminal in terms of transmit power efficiency. It is currently aworking assumption for uplink multiple access scheme in 3GPP Long TermEvolution (LTE), or Evolved UTRA.

In some aspects the teachings herein may be employed in a network thatincludes macro scale coverage (e.g., a large area cellular network suchas a 3rd Generation (3G) networks, typically referred to as a macro cellnetwork) and smaller scale coverage (e.g., a residence-based orbuilding-based network environment). As a wireless communication devicemoves through such a network, the wireless communication device may beserved in certain locations by access nodes that provide macro coveragewhile the wireless communication device may be served at other locationsby access nodes that provide smaller scale coverage. In some aspects,the smaller coverage nodes may be used to provide incremental capacitygrowth, in-building coverage, and different services (e.g., for a morerobust user experience). In the discussion herein, a node that providescoverage over a relatively large area may be referred to as a macronode.

FIG. 1A illustrates a first example wireless communication network 100.The illustrated wireless communication network comprises a macro node102, a cell 104, a wireless communication device 106, and a wirelesscommunication device 108. The wireless communication network 100 isconfigured to support communication between a number of users. Althoughthe wireless communication network 100 is illustrated as containing onlyone cell 104, the wireless communication network may comprise any numberof cells. Communication coverage in cell 104 may be provided by themacro node 102, which may comprise, for example, a base station. Themacro node 203 may interact with a plurality of wireless communicationdevices, for example, wireless communication devices 106 and 108.

Each of the wireless communication devices may communicate with macronode 102 on a forward link (FL) and/or a reverse link (RL) at a givenmoment. A FL is a communication link from a macro node to a wirelesscommunication device. A RL is a communication link from a wirelesscommunication device to a macro node. The macro node 102 may beinterconnected to macro nodes in other cells (not shown in this figure),for example, by appropriate wired or wireless interfaces. Accordingly,the macro node 102 may communicate with wireless communication devicesin other cells (not shown in this figure).

With continuing reference to FIG. 1A, the cell 104 may cover only a fewblocks within a neighborhood or several square miles in a ruralenvironment. Each cell may be further divided into one or more sectors(not shown in this figure). By including additional cells, the wirelesscommunication network 100 may provide service over a large geographicregion, as is well known in the art.

A wireless communication device (e.g., 106) may be a wirelesscommunication device (e.g., a mobile phone, router, personal computer,server, etc.) used by a user to send and receive voice or data over acommunications network. A wireless communication device may be referredto as an access terminal (AT) may also be referred to herein as a userequipment (UE), as a mobile station (MS), or as a terminal device. Asshown, wireless communication devices 106 and 108 may comprise mobilephones. However, the wireless communication devices may comprise anysuitable communication device.

It may be desirable for a wireless communication device (e.g., 106) totransmit information to and receive information from another wirelesscommunication device, such as wireless communication device 108 or awireless communication device in another cell (not shown in thisfigure). The wireless communication device 106 may accomplish this byfirst communicating with the macro node 102 via a wireless link. Forexample, the wireless communication device 106 may generate and transmita message to the macro node 102. The macro node 102 may then generateand transmit a message to another wireless communication device, such aswireless communication device 108. The message may comprise informationrelated to various types of communication (e.g., voice, data, multimediaservices, etc.) and may include packets having one or more extensionheaders, as discussed in detail below with reference to FIGS. 4-13.

FIG. 1B illustrates a second example wireless communication network 200.The illustrated wireless communication network 200 comprises thewireless communications device 106, a second wireless communicationsdevice 210, a third wireless communications device 220, and a fourthwireless communications device 230. The wireless communication network200 may be configured to support communication between a multitude ofdevices, such as the wireless communications devices 106, 210, 220 and230. The wireless communications devices (e.g., 210, 220) may comprise,for example, personal computers, PDAs, music players, video players,multimedia players, televisions, electronic game systems, digitalcameras, video camcorders, watches, remote controls, headsets, and soon. Although the wireless communications device 106 is illustrated inboth FIGS. 1 and 2, the wireless communications device 106 need not bein communication with the wireless communication network 200 and thewireless communication network 100 of FIG. 1A simultaneously.

With continuing reference to FIG. 1B, the wireless communications device106 may communicate with other wireless communications devices (e.g.,210, 220) over a variety of communication channels. The communicationchannels may comprise Ultra-Wide Band (UWB) channels, Bluetoothchannels, 802.11 channels (e.g., 802.11a, 802.11b, 802.11g, 802.11n),infrared (IR) channels, ZigBee (802.15) channels, or a variety of otherchannels, as is well known in the art. In one embodiment, the channelmay be a UWB channel conforming to the ECMA-368 standard.

The wireless communications network 200 may comprise a wireless localarea network (WLAN) covering a physical area, like a home, office, or agroup of buildings. A WLAN may use standards such as, 802.11 standard(e.g., 802.11g), and/or other standards for wireless communications. AWLAN may use peer-to-peer communication in which the wirelesscommunication devices directly communicate with each other. The wirelesscommunications network 200 may also comprise a wireless personal areanetwork (WPAN), spanning, for example, an area of a few meters. A WPANmay use standards such as infrared, Bluetooth, a WiMedia based UWBstandard (e.g., ECMA-368), and ZigBee standards, and/or other standardsfor wireless communications. A WPAN may use peer-to-peer communicationin which the wireless communication devices directly communicate witheach other. The wireless communications network 200 may connect toanother network, such as the wireless communications network 100 or theInternet, through a device such as the wireless communications device106.

The messages sent across the wireless communications network 200 maycomprise information related to various types of communication (e.g.,voice, data, multimedia services, etc.) and may include packets havingone or more extension headers, as discussed in detail below withreference to FIGS. 4-12.

Although the following embodiments may refer to FIG. 1B and particularlythe ECMA-368 standard, they may also be applicable to the communicationsystem 100 shown in FIG. 1A and other communication standards. Forexample, one embodiment may be applicable in a UMTS communicationsystem. Another embodiment may be applicable in a OFDMA communicationsystem. Some embodiments may be applied to any communication systemwhich uses padding bits when transmitting data from one wirelesscommunication device to another wireless communication device.Generally, padding bits are bits within a frame (e.g., a unit of dataused by a communication system) that are used to “pad” a frame to acertain length. For example, the communication system 200 may requirethat all frames sent between the wireless communication devices (e.g.,106 and 220) be 256 bits in length. If the wireless communication device106 only has 128 bits of data to send in a frame, the wirelesscommunication device 106 may use 128 padding bits to fill the rest ofthe frame such that the total length of the frame meets the 256 bitlength requirement.

The ECMA-368 standard specifies a physical layer (PHY) and a mediumaccess control (MAC) sublayer for ultra-wideband (UWB) communicationsystems. For example, the ECMA-368 standard may be used in a high-speed,short-range wireless network. The ECMA-368 standard may use all or partof the frequency spectrum between 3100-10,600 MHz and may support datarates of up to 480 Mb/s. The ECMA-368 standard divides the spectrum into14 bands, each with a bandwidth of 528 MHz. The ECMA-368 standard mayuse a multi-band orthogonal frequency division modulation (MB-OFDM)scheme to transmit information. Frequency-domain spreading, time-domainspreading, and forward error correction (FEC) coding are provided foroptimum performance under a variety of channel conditions.

The MAC sublayer of the ECMA-368 standard may allow a group of devicesto continue communicating while merging or splitting from other groupsof devices. The functionality of this MAC may be distributed amongmultiple devices. These functions include distributed coordination toavoid interference between different groups of devices by appropriateuse of channels and distributed medium reservations to ensure Quality ofService. The MAC sublayer of the ECMA-368 may provide prioritizedschemes for isochronous and asynchronous data transfer. To do this, theECMA 368 standard may use one of Carrier Sense Multiple Access (CSMA) orTime Division Multiple Access (TDMA). The MAC sublayer of the ECMA-368standard may ensure equitable sharing of the bandwidth.

FIG. 2 is a functional block diagram of an example wirelesscommunication device 106 shown in FIGS. 1A and 1B. As discussed above,the wireless communication device 106 may be a mobile phone. Thewireless communication device 106 may comprise a processor 200configured to process information for storage, transmission, and/or forthe control of other components of the wireless communication device106. The processor 200 may further be coupled to a memory 204. Theprocessor may read information from or write information to the memory204. The memory 204 may be configured to store messages before, duringor after processing. The memory 204 may also store extension header dataand/or one or more packets having extension headers, as will bediscussed in further detail below with reference to FIGS. 6-12. Theprocessor 200 may also be coupled to a wireless network interface 208.The wireless network interface 208 may be configured to receive aninbound wireless message from, and transmit an outbound wireless messageto a macro node (e.g., 102) and/or to another wireless communicationdevice (e.g., 220). The inbound wireless message may be passed to theprocessor 200 for processing. The processor 200 may process packetshaving one or more extension headers.

The processor 200 may process the outbound wireless message passing theoutbound wireless message to the wireless network interface 208 fortransmission. Additionally, the processor 200 may identify extensionheaders for sending and include them in the message, as will bediscussed in detail below with reference to FIG. 12. The processor 200may also be coupled to a message interpreter 206. The inbound wirelessmessage received at the wireless network interface 208 from the macronode 102 and/or another wireless communication device (e.g., 220) may bepassed to the processor 200 and passed by the processor 200 to themessage interpreter 206 for additional processing. The messageinterpreter 206 may also be coupled to the memory 204 to store orretrieve information for use in message interpreting. The messageinterpreter 206 may interpret packets having one or more extensionheaders. In one embodiment, described below with reference to FIGS. 9and 12, the message interpreter 206 may process one or more fragmentedextension headers.

The processor 200 may also be coupled to a message formatter 202. Themessage formatter 202 may generate or format the outbound wirelessmessage to be transmitted by the wireless network interface 208. Thewireless outbound message may be passed by the message formatter 202 tothe processor 200 for transmission by the wireless network interface 208to a macro node (e.g., 102) and/or another wireless communication device(e.g. 220). The message formatter 202 may be coupled directly to thememory 204 in order to store or retrieve information for use in messageformatting. The message formatter 202 may insert extension headers orextension header frame check sequence, tail or pad bits into one or morepackets, as described in detail below with reference to FIGS. 6-12.

The wireless network interface 208 may comprise an antenna and atransceiver. The transceiver may be configured to modulate/demodulatethe outbound/inbound wireless messages going to or coming from the macronode 102 and/or another wireless communication device (e.g. 220). Theantenna may transmit/receive the outbound/inbound wireless messages. Theantenna may be configured to communicate with the macro node 102 overone or more channels. The outbound/inbound wireless message may comprisevoice and/or data-only information (collectively referred to herein as“data”). The wireless network interface 208 may demodulate the datareceived. The wireless network interface 208 may modulate data to besent from the wireless communication device 106 via the wireless networkinterface 208. The processor 200 may provide data to be transmitted.

The memory 204 may comprise processor cache, including a multi-levelhierarchical cache in which different levels have different capacitiesand access speeds. The memory 204 may also comprise random access memory(RAM), other volatile storage devices, or non-volatile storage devices.The storage may include hard drives, optical discs, such as compactdiscs (CDs) or digital video discs (DVDs), flash memory, floppy discs,magnetic tape, and Zip drives.

Although described separately, it is to be appreciated that functionalblocks described with respect to the wireless communication device 106need not be separate structural elements. For example, the processor 200and the memory 204 may be embodied in a single chip. The processor 200may additionally, or in the alternative, contain memory, such asprocessor registers. Similarly, one or more of the functional blocks orportions of the functionality of various blocks may be embodied in asingle chip. Alternatively, the functionality of a particular block maybe implemented on two or more chips.

One or more of the functional blocks and/or one or more combinations ofthe functional blocks described with respect to the wirelesscommunication device 106, such as processor 200, message interpreter206, and message formatter 202 may be embodied as a general purposeprocessor, a digital signal processor (DSP), an application specificintegrated circuit (ASIC), a field programmable gate array (FPGA) orother programmable logic device, discrete gate or transistor logic,discrete hardware components, or any suitable combination thereofdesigned to perform the functions described herein. One or more of thefunctional blocks and/or one or more combinations of the functionalblocks described with respect to the wireless communication device 106may also be implemented as a combination of computing devices, e.g., acombination of a DSP and a microprocessor, a plurality ofmicroprocessors, one or more microprocessors in conjunction with a DSPcommunication, or any other such configuration.

FIG. 3 is a functional block diagram of an example macro node 102 shownin FIG. 1A. As discussed above with respect to FIG. 1A, the macro node102 may be a base station. The macro node 102 may comprise a wirelessnetwork interface 308 configured to receive an inbound wireless messagefrom and transmit an outbound wireless message to one or more wirelesscommunication devices, such as wireless communication device 106.Wireless network interface 310 may be coupled to the processor 300. Theprocessor 300 may be configured to process the inbound and outboundwireless message coming from or going to the wireless communicationdevice 106 via the wireless network interface 310. The processor 300 mayprocess packets having one or more extension headers.

The processor 300 may also be configured to control other components ofthe macro node 102. The processor 300 may be further coupled to a wirednetwork interface 308. The wired network interface 308 may be configuredto receive an inbound wired message from and to transmit an outboundwired message to other destinations (e.g., other macro nodes and/orwireless communication devices). The wired network interface 308 mayreceive an inbound wired message and pass the inbound wired message tothe processor 300 for processing. The processor 300 may process anoutbound wired message and pass the outbound wired message to the wirednetwork interface 308 for transmission.

The processor 300 may further be coupled, via one or more buses, to amemory 304. The processor 300 may read information from or writeinformation to the memory 304. The memory 304 may be configured to storeinformation for use in processing the inbound or outbound, wired orwireless message. The memory 304 may also store extension header dataand/or one or more packets having extension headers, as will bediscussed in further detail below with reference to FIGS. 6-12. Theprocessor 300 may also be coupled to a message interpreter 306. Theprocessor may pass the inbound wired and wireless message to the messageinterpreter 306 for processing. The message interpreter 306 mayinterpret packets having one or more extension headers. In oneembodiment, described below with reference to FIGS. 9 and 12, themessage interpreter 306 may process one or more fragmented extensionheaders.

The message interpreter 306 may also be configured to extractinformation from the inbound wireless message received at the wirelessnetwork interface 310. For example, the inbound wireless messagereceived from the wireless communication device may comprise packageextension headers. The message interpreter 306 may extract the packageextension headers from the inbound wireless message provided by thewireless communication device. The message interpreter 306 may pass thisidentifying information to the processor 300 for additional processing.In another example, the message interpreter 306 may be configured toprocess the inbound wireless message and to provide the processor 300with information for responding to the inbound wireless message byrequesting additional information. The message interpreter 306 may alsobe coupled directly to the memory 304 in order to store or retrieveinformation for use in message interpretation.

The processor 300 may also be coupled to a message formatter 302. Themessage formatter 302 may be configured to generate the outbound wiredor wireless message. The message formatter 302 may be further configuredto pass the generated outbound wired or wireless message to theprocessor 300. The message formatter 202 may insert extension headers orextension header frame check sequence, tail or pad bits into one or morepackets, as described in detail below with reference to FIGS. 6-12.

The processor 300 may pass the outbound wired or wireless message to thewired network interface 308 or the wireless network interface 310 fortransmission. Additionally, the processor 300 may identify extensionheaders for sending and include them in the message, as will bediscussed in detail below with reference to FIG. 12. The wired networkinterface 308 may transmit the outbound wired message to another macronode. The message formatter 302 may pass the outbound wireless messageto the processor 300. The processor 300 may pass the outbound wirelessmessage to the wireless network interface 310 for transmission to thewireless communication device 106. The message formatter 302 may also becoupled directly to the memory 304 in order to store or retrieveinformation for use in message formatting.

The wireless network interface 310 may comprise an antenna and atransceiver. The transceiver may be configured to modulate/demodulatethe outbound/inbound wireless messages going to or coming from awireless communication device. The antenna may transmit/receive theinbound/outbound wireless messages. The antenna may be configured tosend and/or receive the outbound/inbound wireless messages from themacro node 102 over one or more channels. The outbound/inbound wirelessmessages may comprise voice and/or data-only information (collectivelyreferred to herein as “data”) and may include one or more packets havingextension headers. The wireless network interface 310 may demodulate thedata received. The wireless network interface 310 may modulate data tobe sent from the macro node 102 via the wireless network interface 310.The processor 300 may provide data to be transmitted.

The wired network interface 308 may comprise a modem. The modem may beconfigured to modulate/demodulate the outbound/inbound wired messagegoing to or coming from another destination/source, such as anothermacro node. The wired network interface 308 may demodulate the datareceived according to one or more wired standards using methods known inthe art. The demodulated data may be transmitted to the processor 300.The wired network interface 308 may modulate data to be sent from themacro node 102 via the wired network interface 308 according to one ormore wired standards using methods known in the art. The processor 300may provide data to be transmitted.

The memory 304 may comprise a processor cache, including a multi-levelhierarchical cache in which different levels have different capacitiesand access speeds. The memory 304 may also comprise random access memory(RAM), other volatile storage devices, or non-volatile storage devices.The storage may include hard drives, optical discs, such as compactdiscs (CDs) or digital video discs (DVDs), flash memory, floppy discs,magnetic tape, and Zip drives

Although described separately, it is to be appreciated that functionalblocks described with respect to the macro node 102 need not be separatestructural elements. For example, the processor 300 and the memory 304may be embodied in a single chip. The processor 300 may additionally, orin the alternative, contain memory, such as processor registers.Similarly, one or more of the functional blocks or portions of thefunctionality of various blocks may be embodied in a single chip.Alternatively, the functionality of a particular block may beimplemented on two or more chips.

One or more of the functional blocks and/or one or more combinations ofthe functional blocks described with respect to the macro node 102, suchas processor 300, message interpreter 306, and message formatter 302,may be embodied as a general purpose processor, a digital signalprocessor (DSP), an application specific integrated circuit (ASIC), afield programmable gate array (FPGA) or other programmable logic device,discrete gate or transistor logic, discrete hardware components, or anysuitable combination thereof designed to perform the functions describedherein. One or more of the functional blocks and/or one or morecombinations of the functional blocks described with respect to themacro node 102 may also be implemented as a combination of computingdevices, e.g., a combination of a DSP and a microprocessor, a pluralityof microprocessors, one or more microprocessors in conjunction with aDSP communication, or any other such configuration.

The functionality of the modules of FIGS. 2-3 may be implemented invarious ways consistent with the teachings herein. In some aspects thefunctionality of these modules may be implemented as one or moreelectrical components. In some aspects the functionality of these blocksmay be implemented as a processing system including one or moreprocessor components. In some aspects the functionality of these modulesmay be implemented using, for example, at least a portion of one or moreintegrated circuits (e.g., an ASIC). As discussed herein, an integratedcircuit may include a processor, software, other related components, orsome combination thereof. The functionality of these modules also may beimplemented in some other manner as taught herein. The functionalitydescribed herein (e.g., with regard to one or more of the accompanyingfigures) may correspond in some aspects to similarly designated “meansfor” functionality in the appended claims. Referring to FIGS. 1-3, themacro node 102 and the wireless communication device 106 are representedas a series of interrelated functional modules.

FIG. 4 illustrates an example frame structure conforming to the ECMA-368standard. The physical layer convergence protocol (PLCP) protocol dataunit or PPDU or frame structure 400 comprises a PLCP preamble 402, aPLCP header 404 and a physical layer service data unit or PSDU 406. TheECMA-368 standard defines an ultra wide band physical (PHY) layer andmedium access control (MAC) sublayer to support a wireless communicationnetwork (e.g., 100). Thus, in one embodiment a wireless communicationdevice (e.g., 106) may have, for example, a wireless network interface(e.g., 208) and/or processor (e.g., 200) configured to receive aninbound wireless message from and transmit an outbound wireless messageto one or more other wireless communication devices (e.g., 210, 220, and230) using the ECMA-368 standard. The PSDU 406 may include bits of datarelated to various types of communications (e.g., voice, data,multimedia services, etc.) contained in a packet sent to and/or from awireless communication device (e.g., 106) and another wirelesscommunication device (e.g., 220). It will be understood that althoughthe wireless communication network 200 may utilize the ECMA-368standard, this selection is merely illustrative, and the embodimentsdescribed below with reference to FIGS. 6-13 are applicable tocommunication networks utilizing a variety of standards.

As illustrated in FIG. 4, the PSDU 406 comprises a frame payload 410, aframe check sequence, tail bits, and pad bits 412. The frame payload 410may comprise bits of data related to various types of communications(e.g., voice, data, multimedia services, etc.) contained in a packetsent to and/or from a wireless communication device (e.g., 106) toanother wireless communication device (e.g., 220). The frame checksequence provides checksum characters for the frame to aid in errordetection and correction. In embodiments where the wireless networkinterface (e.g., 208 or 308) contains a convolution decoder, the tailbits may be added to flush out the decoder so as to reset it to itsinitial state and improve error probability. The ECMA-368 standardprovided that the bit stream be interleaved prior to modulation toprovide robustness against burst errors. Accordingly, the standardprovides for the pad bits 412 to ensure the PSDU 406 is aligned on theboundary of the interleaver.

With continuing reference to FIG. 4, the PLCP preamble 402 may aid thewireless network interface (e.g., 208 or 308) in timing synchronization,carrier-offset recovery, and channel estimation. The PLCP preamble 402in the ECMA-368 standard consists of a packet/frame synchronizationsequence followed by a channel estimation sequence.

The PLCP header 404 may convey information to a wireless networkinterface (e.g., 208 or 308) for use in decoding the PSDU 406. Asillustrated in FIG. 4, the PLCP header 404 comprises a PHY header 408, aMAC header, a header check sequence, Reed-Solomon parity bytes, andthree fields of tail bits. The PHY header 408 will be discussed indetail below with reference to FIG. 5. The header check sequence andReed-Solomon parity bytes provide improved error detection andcorrection for the PLCP header 404. Additionally, in embodiments wherethe wireless network interface contains a convolution decoder, the tailbits may be added to flush out the decoder so as to reset it to itsinitial state and improve error probability. In the ECMA-368 standard,the MAC header is scrambled with the header check sequence prior totransmission in order to decrease the probability of transmission error.

FIG. 5 illustrates a PHY header bit assignment for the frame structureof FIG. 4. The PHY header 408 includes a length field 506, whichindicates the length of the frame payload (e.g., 410) not including theframe check sum, tail bits or pad bits. The PHY header 408 also includesreserved bits. These bits are reserved in the ECMA-368 standard forfuture use and are set to zero in the current standard. For purposes ofillustration only, the PHY header 408 includes a first reserved field502 and a second reserved field 504.

The first reserved field 502 and second reserved field 504 may be usedin one or more embodiments, as described below. In one embodiment, thefirst reserved field 502 is used to indicate the presence and content ofone or more extensions headers, as described below in detail withreference to FIGS. 6-13. In another embodiment, the second reservedfield 504 is used to keep the transmitter (e.g., 208 or 308) andreceiver (e.g., 208 or 308) synchronized with respect to the CSI. Inparticular, there may be a version number of the extension header beingused for the current PSDU transmission in the second reserved field 504of the PLCP header 404. The interval between successive feedbacksensures that there will be no issue when the version number wraps aroundafter eight feedbacks. Although the embodiments described above areillustrated in the context of the first reserved field 502 and thesecond reserved field 504, the embodiments described are applicable toany of the reserved bits.

The PLCP header 404 of FIG. 4 includes both the PHY and MAC header.Although the embodiments described below with reference to FIGS. 6-13are applicable to frame structures that have a common PHY header and MACheader such as in the ECMA-368 and ECMA-387 standards, the embodimentsare also applicable to a variety of frame structures, including thosewith a limited number of reserved bits available for PHY headerextension. Another embodiment may also be applicable to communicationsystems and/or standards with separate PHY and MAC headers (e.g., 802.11standards).

In certain communication systems, it may be desirable to extend the PHYheader 408 and the MAC header to accommodate for more fields for nextgeneration equipment designs. Such next generation equipment wouldtypically require more header data than existing or predecessorequipment. It may be also desirable to extended headers to provide acontrol channel incurring zero or minimal overhead. For example, thecontrol information in ECMA-368 may be sent in one of three ways—asbeacons, command or control frames, or piggybacked with other traffic.Beacons may be sent once every 65.536 ms in the ECMA-368 standard whichmay be less frequent than needed. On the other hand, control and commandframes require separate Distributed Reservation Protocol (DRP)reservations and result in more overhead with separate preamble, header,and interframe spacing. Since each pair of transmitter and receiverrequires separate DRP reservations for sending their frames, this methoddoes not scale well with number of devices. Thus, there is a need toextend the PHY header 408 and the MAC header to provide a controlchannel incurring zero or minimal overhead. In another embodiment,prioritized contention access (PCA) may be used to send command andcontrol information and/or frames. In a system using PCA, differentdevices (e.g., wireless communication devices 106 and 220) may competeagainst each other to transmit frames (e.g., command and control frames)during a certain time period. Some types of frames (e.g., data packets)may be given a higher priority. The highest priority frame and/or framesmay be transmitted during the contested time period.

Generally, there maybe a limited number of bits available or reserved inexisting headers, but such reserved bits may not be sufficient toaccommodate for header extensions. Extending the header field itselfbeyond those reserved bits (e.g., adding header bits to the headerfield) may not keep the header compatible with legacy devices as thelegacy devices may not be able to decode the new header and verify aheader check sequence. Accordingly, a scalable header extensionstructure that allows for header extension beyond the reserved bitswhich is also compatible with legacy devices may be desirable. Ascalable header extension structure according to a certain embodimentmay allow the extension headers to be transmitted and/or receivedwithout increasing the duration of the frame. Transmitting the headerextension without increasing the frame duration may help facilitatecompatibility with legacy devices. Another embodiment may allowextension headers(s) to be transmitted without needing additional timeslots (e.g., without extending the reservation duration and/ortransmitting the extension headers as additional frames) to transmit theextension header data/information. In one embodiment, overhead such as aseparate preamble, header, and interframe spacing may be reduced. Thismay increase the efficiency in the use of the system. In anotherembodiment, padding bits (bits which are only used to “pad” a frame to acertain length) may be used. Using these padding bits may allowgenerally non-useful bits to be used to transmit data, such as headerextension data. This may also increase the efficiency in the use of thesystem, as previously non-useful bits may be used to transmit data.

FIG. 6 is an example scalable header extension structure according to anillustrative embodiment. The exemplary scalable header extensionstructure 600 comprises the PLCP header 404, a first extension header606, a second extension header 610, a Nth extension header 614, and theactual frame payload 410. Each extension header may point to anotherextension header or to the actual frame payload 410 by using one or moreindicator bits.

Despite the limited number of reserved bits in the PLCP header 404 asdiscussed above, a wireless communication device (e.g., 106) may createa scalable header extension structure 600 by inserting one or moreextension headers in front of the actual frame payload 410 when needed.A processor (e.g., 200 or 300) may create the scalable header extensionstructure 600. Extension headers may be used to send various types ofinformation or content over a wireless communication network (e.g.,100), as will be discussed in detail below. The information or contentmay be sent to and/or from a wireless communication device (e.g., 106)to another wireless communication device (e.g., 210, 220, or 230).

The extension headers may be used to send various types of informationor content. For example, one or more of the extension headers might beused to send information not needed to decode the current PSDU, ornon-critical content not needing the robustness of its own PLCP header.In one embodiment, the extension header includes information that issent optionally on a best effort basis when there is not enough room inthe PSDU. In another embodiment, the extension header includes contentreceived by a wireless network interface (e.g., 208 or 308) overmultiple frames. A memory of a wireless communication device (e.g., 106)may store the extension headers.

The extension headers may also be used to send control information. Forexample, the information could comprise channel state information (CSI)feedback for adaptive allocation of resources by the wireless networkinterface (e.g., 208 or 308). In particular, the information includecontent directed toward transmit power, data rates, modulation orcoding. In one embodiment, the extension header includes local linkscheduling information. In another embodiment, the extension headerincludes out of band control information. Although reference has beenmade to the extension header being used to send certain types ofcontent, the extension headers may be used to send any type ofinformation, including other control information not listed above.

With continuing reference to FIG. 6, in one embodiment, the presence ofthe first extension header 606 is indicated by reserved bits in the PLCPheader 404. For example, with reference back to FIG. 5, the firstreserved field 502 of the PHY header 408 could be used to indicatewhether or not the first extension header 606 is present. The bits usedfor indication may comprise one or more other bits, including any of thereserved bits of the PHY header 408. In one embodiment, the bits usedfor indication indicate the presence and content of the first extensionheader 606, as will be described below with reference to Table 1. Thebits used for indication may be inserted by a processor (e.g., 200 or300) or a message formatter (e.g., 202 or 302).

TABLE 1 Next Extension Header Extension Header Content 0 No MoreExtension Header 1 CSI 2 Link Scheduling 3 Out of Band ControlInformation 4-7 Reserved

Table 1 demonstrates one possible encoding scheme for indicating thepresence and content of the next extension header. For example, thepresence of the first extension header 606 may be indicated by one ormore reserved bits of the PLCP header 404 as described above. In theillustrated encoding scheme using three bits, the value of the encodedbits may be used to determine the presence and content of the firstextension header 606. For example, if the encoded value of the bits wereone, this may indicate that the first extension header 606 comprises CSIcontent. Similarly, if the encoded value of the bits were zero, this mayindicate that the first extension header 606 is not present, and thatthe actual frame payload 410 immediately follows the PLCP header 404.

With continuing reference to FIG. 6 and Table 1, the bits indicating thepresence of the second extension header 610 may comprise one or morebits of the first extension header 606. The bits used for indicating thesecond extension header 610 may be encoded using the encoded schemedescribed in Table 1. Thus, if the encoded value of the indicator bitscorresponding to the second extension header 610 were two, this mayindicate that the second extension header 610 comprises link schedulingcontent. Similarly, if the encoded value of the bits were zero, this mayindicate that the second extension header 610 is not present, and thatthe actual frame payload 410 immediately follows the first extensionheader 606. Bits indicating the presence of the Nth extension header 614may be implemented in a similar manner using the encoding scheme ofTable 1.

The scalable header extension structure 600 described above correspondsto a daisy-chain of extension headers. One or more indicator bits in thePLCP header 404 may point to the first extension header 606, as shown inthe abstract by the first arrow 604. Likewise, one or more indicatorbits in the first extension header 606 may point to the second extensionheader 610, as shown in the abstract by the second arrow 608.Analogously, third arrow 612 and fourth arrow 616 may be used to furtherrepresent the daisy-chain of extension headers in the abstract. Otherscalable header extension structures besides a daisy-chain are possible.For example, one or more reserved bits in the PLCP header 404 mayindicate whether or not extension headers are present and/or the numberof extension headers present. In one embodiment, if the bits indicatethe presence of one or more extension headers, a field containing anarray of header extension indicator fields may be placed after the PLCPheader 404.

FIG. 7 illustrates an example modified ECMA-368 frame structure inaccordance with the scalable header extension structure of FIG. 6. Themodified frame structure 700 comprises the PLCP preamble 402, the PLCPheader 404, an extended PLCP header 702 and the PSDU 406. In contrast tothe frame structure defined by the ECMA-368 standard (e.g., 400), themodified frame structure 700 includes the extended PLCP header 702inserted into the payload of the PSDU 406 between the PLCP header 404and the actual frame payload 410. The PLCP header 702 may be inserted byusing a daisy chain of extension headers as described above withreference to FIG. 6.

In the ECMA-368 standard, the maximum PSDU length is 4095 bytes,corresponding to a maximum value of the 12-bit length field 506,illustrated in FIG. 5. In one embodiment, the extended PLCP header 702is inserted into payload of the PSDU 406 before the actual frame payload410, and the length field 506 indicates the length of the actual framepayload plus the length of the extended PLCP header. A message formatter(e.g., 202 or 302), and/or a processor (e.g., 200 or 300) could performthis insertion.

Although the illustrated extended PLCP header 702 is shown as beinginserted into the payload of the PSDU 406 between the PLCP header 404and the actual frame payload 410, the extended PLCP header 702 may beinserted in a variety of ways. For example, in one embodiment, theextended PCLP header 702 is inserted into the pad bits 412, as discussedbelow.

In the current ECMA-368 system, padding bits may be inserted in order toalign the data stream on the boundary of the symbol interleaver. Forexample, ECMA-368 provides that pad bits are inserted so that the datastream is aligned on 6 orthogonal frequency division modulation (OFDM)symbol boundaries. In one embodiment, one or more extension headers aresent in the pad bits 412 of the PSDU 406.

For illustrative purposes only, it is useful to consider the followingprobabilistic model of sending extension headers in the pad bits 412.Additional details of the model may be found in Das et al., ScalablePLCP Header Extension within PSDU, ICUWB 2009, which is hereinincorporated by reference in its entirety. Let the number of pad bits412 in a given frame be x, and the total length of the extension headerelements desired to be inserted in the pad bits 412 be A bits. For thepurposes of this model, x may be modeled as a uniform probabilitydistribution.

Thus x may vary from 0 to P-1, where P corresponds to the number ofinformation bits in 6 OFDM symbols at a given PHY data rate at which theframe payload is transmitted. The number of information bits in 6 OFDMsymbols is defined by the ECMA-368 standard, and varies with data rate,as shown below in Table 2.

TABLE 2 Data Rate (Mb/s) Bits per 6 OFDM Symbols (P) 53.3 100 80 150106.7 200 160 300 200 375 320 600 400 750 480 900

If A<P we may partition the range of x into two parts. In the firstpartition, x<A and the extension header does not fit in the pad bits412. If the extension header were inserted into the pad bits 412,additional padding bits would be needed to align the data stream on 6OFDM symbol boundaries as required by the ECMA-368 standard. In thesecond partition, x≧A and the extension header will fit in the pad bits412. Thus,

$\frac{A}{P}$

is the probability that the extension header will not fit in the padbits 412 without having to extend the PSDU 406. In one embodiment, when

$\frac{A}{P}$

is small, an extension header is unconditionally placed in the pad bits412. Although the PSDU 406 must be extended in a small fraction oftransmissions, the overhead of PLCP preamble and PLCP header isamortized, as will be described below with reference to FIG. 13. Inanother embodiment, the extension header is placed in the pad bits 412only when then the extension header fits in the pad bits 412. In yetanother embodiment, if the extension header does not fit into the fieldsavailable for padding, an extension header fragment fitting in the padbits 412 is sent, as will be described below with reference to FIG. 9.

If A≧P the PSDU duration must be extended. In particular, the PSDU mustbe extended by

$\lbrack {{{floor}\mspace{14mu} ( \frac{A}{P} )} + y} \rbrack$

number of 6 symbol durations, where, y=0 if mod(A,P)≦x<P and y=1 if0≦x<mod(A,P). Thus in this case, we always incur floor

$( \frac{A}{P} )$

number of additional 6 symbol durations and probabilistically on

$\frac{{mod}( {A,P} )}{P}$

occasion, we incur an additional 6 symbol duration. In one embodiment,the extension header may not fit in the available padding bits which mayresult in extending the duration of the PSDU unconditionally in the padbits 412. Although the PSDU 406 must be extended by one or moreadditional 6 symbol durations, the overhead of PLCP preamble, PLCPheader and inter-frame spacing may be amortized.

Although inserting the extended PCLP header 702 into the pad bits 412was described above with reference to a particular model, this was forillustrative purposes only, and was not intended to limit theembodiments described above in any way.

FIG. 8 is an example extended PLCP header structure 702 according to afirst embodiment. The illustrated extended PLCP header 702 includes afirst extension header having a first extension header indicator 802, afirst extension length 804, and first extension information 806. Theextended PLCP header 702 may also include a second extension headerhaving a second extension header indicator 808, a second extensionlength 810, and second extension information 812. The extended PLCPheader 814 further includes pad bits 814, located after all extensionheaders. Although the illustrated PLCP header 702 includes at least twoextension headers, the PLCP header structure could include any number ofextension headers. For example, in one embodiment, the PLCP header 702may include one, two, or three extension headers. In another embodiment,the PLCP header structure may include no extension header.

The illustrated extended PLCP header 702 may be used in the embodimentsdescribed above with reference to FIGS. 6-7. The first extension headerindicator 802 may be implemented as described above with reference toFIG. 6 and Table 1. In particular, an extension header indicator (e.g.,802 or 804) may indicate the presence and content of a subsequentextension header as described above. Reserved bits in the PLCP Header(e.g., 404) may indicate the presence of the first extension header.Other extension header indicators (e.g., 806) may be in the precedingextension headers.

The illustrated extended PLCP header 702 includes the first extensionlength 804 and the second extension length 806. The first extensionlength 804 may indicate the length of the first extension information806. Similarly, the second extension length 810 may indicate the lengthof the second extension information 812. In one embodiment, theextension length is 10 bits and indicates the length of the extensionheader information in bits.

With continuing reference to FIG. 8, the illustrated extended PLCPheader 702 includes the pad bits 814. The pad bits 814 may be used tobyte align the one or more extension headers. In some embodiment the padbits 814 may not be needed. For example, if the extension lengthindicates the length of the extension header in bytes, the extensionheaders are automatically byte aligned.

In one embodiment, the extension length fields are used by a messageinterpreter (e.g., 206 or 306) and/or processor (e.g., 200 or 300) tospeed up time sensitive processing. In particular, the extension lengthfields provide the flexibility to process extension header elementsoff-line as needed. To locate the start of the payload, the messageinterpreter (e.g., 206 or 306) and/or processor (e.g., 200 or 300) mayuse the length fields to skip over extension header information to reachthe start of the actual frame payload.

FIG. 9 illustrates an example coding table for the extension headerinformation field of the extended PLCP header structure of FIG. 8. Theillustrated extension header information 900 comprises a version field,a fragment field, and a payload field. The extension header information900 illustrates one of many possible formats for extension information(e.g., 806 or 812).

The version field may be used to keep the transmitter and receiversynchronized with respect to updates in extension header information.For example, if the extension header is being used to communicate CSI,the version field may indicate a specific version of CSI. In oneembodiment, the version field is three bits.

With continuing reference to FIG. 9, the fragment number field may beused if the entire extension header does not fit in the current PSDU.For example, as described above with reference to FIG. 7, the maximumPSDU length is 4095 bytes in the ECMA-368 standard. Accordingly, someextension headers may be too large to fit into a given PSDU since thelength field in the PLCP header generally indicates the length of thepayload plus the length of the extension headers. The fragment numberfield may allow the extension header to be sent in more than one PSDU.Additionally, as described above with reference to FIG. 7, in someembodiments one or more extension headers may be placed in the pad bits412. If an extension header does not fit into the pad bits 412, anextension header fragment having a fragment number field may be insertedinto the pad bits 412 and sent instead.

The payload field may contain the information or content of theextension header. This information may include CSI, link scheduling, outof band control, or a variety of other types of content as describedabove with reference to FIG. 6. In one embodiment, the length of thepayload field is specific to the header extension type. For example,with reference back to Table 1, the length of the payload field may varydepending on whether the extension header contained CSI, link schedulingor out of band control content.

FIG. 10 is an example extended PLCP header structure according to asecond embodiment. The illustrated extended PLCP header 1000 includes afirst extension header having a first extension header indicator 802, afirst extension length 804, and first extension information 806. Theextended PLCP header 1000 also includes a second extension header havinga second extension header indicator 808, a second extension length 810,and second extension information 812. The extended PLCP header 814further includes a frame check sequence 1002, tail bits 1004, and padbits 814, located after the extension headers. Although the illustratedPLCP header 1000 includes at least two extension headers, the PLCPheader structure could include any number of extension headers.

The illustrated extended PLCP header 1000 may offer improved errordetection and correction as compared to the extended PLCP header 702 ofFIG. 8. The addition of the frame check sequence 1002 and the tail bits1004 to the extended PLCP header may decouple errors in the actual framepayload from errors in the extension header. The frame check sequence1002 provides checksum characters specific to the extended PLCP header1000 to improve error detection and correction. In one embodiment, theframe check sequence 1002 is 32 bits. If the wireless network interface(e.g., 208 or 308) contains a convolution decoder, the tail bits 1004may be added to flush out the decoder so as to reset it to its initialstate and improve error probability. In particular, the addition of thetail bits 1004 may decouple the error in the actual frame payload fromthe error in the extension header and are especially beneficial whenprefixed to a large frame payload.

FIG. 11 is an example extended PLCP header structure according to athird embodiment. The illustrated extended PLCP header 1100 includes afirst extension header having a first extension header indicator 802, afirst extension length 804, first extension information 806, a firstframe check sequence 1102, and first tail bits 1104. The extended PLCPheader 1100 also includes a second extension header having a secondextension header indicator 808, a second extension length 810, secondextension information 812, a second frame check sequence 1106, andsecond tail bits 1108. The extended PLCP header 814 further includes padbits 814, located after the extension headers. Although the illustratedPLCP header 1100 includes at least two extension headers, the PLCPheader structure could include any number of extension headers.

The illustrated extended PLCP header 1100 may offer improved errordetection and correction as compared to both the extended PLCP header702 of FIG. 8 and the extended PLCP header 1000 of FIG. 10. Inparticular, the addition of a frame check sequence and tail bits to eachextension header may decouple errors in the actual frame payload fromerrors in the extension header. Although only a first frame checksequence 1102, first tail bits 1104, second frame check sequence 1106,and second tail bits 1108 are illustrated, the addition of moreextension headers to the PLCP header 1100 may result in the addition ofmore frame check sequences and tail bits.

FIG. 12 is a method of extending a PCLP header according to oneembodiment. It will be understood that not all of the illustrated stepsare required, and that this method may be modified without departingfrom the spirit and scope of the invention. Additionally, this methodmay be implemented using one or more processors, formatters,interpreters, memories, and/or other devices, as will be described infurther detail below. The illustrated method 1200, depicted from thepoint of view of a transmitting device (e.g., 102 or 106), starts at1200. In an ensuing step 1202, the transmitting device identifiesextension headers for sending to a receiving device (e.g., 102 or 106).A processor (e.g., 200 or 300) may perform this identification, and theidentified extension headers may be present in a memory (e.g., 204 or304), or come from another source, such as a wired network interface(e.g., 308).

In the ensuing decision step 1206, the transmitting device (e.g., 102 or106) determines if there is at least one extension header to be sent. Aprocessor (e.g., 200 or 300) may perform this determination. If theanswer to the decision step is no, the method 1200 proceeds to adecision step 1220, to be described in detail further below.

If the answer to the inquiry in the decision step 1206 is yes, then themethod 1200 proceeds to a step 1208, in which the transmitting device(e.g., 102 or 106) calculates the length of the next extension header.In one embodiment, this calculation is done in bits, while in anotherembodiment it is done in bytes. A processor (e.g., 200 or 300) mayperform this calculation. In an ensuing decision step 1210, thetransmitting device determines if extension headers are sentconditionally. A processor (e.g., 200 or 300) may perform thisdetermination using a memory (e.g., 204 or 304).

If the answer to the inquiry in the decision step 1210 is no, then themethod 1200 proceeds to a step 1212, in which the transmitting device(e.g., 102 or 106), puts the extension header in the frame. Theextension header could be put into the frame by, for example, aprocessor (e.g., 200 or 300) and/or a message formatter (e.g., 202 or302). Additionally, the extension header could be put in the frame at avariety of locations. For example, with reference to FIG. 7, theextension header could be inserted into the pad bits 412 of the PSDU406. In another embodiment, the extension header is put in the payloadof the PSDU 406 between the PLCP header 404 and the actual frame payload410, using a daisy chain of extension headers, as described above withreference to FIG. 6. After the step 1212 is completed, the method 1200returns to the decision step 1206, which was described above.

If the answer to the inquiry in the decision step 1210 is yes, then themethod 1200 proceeds to a step 1214, in which the transmitting device(e.g., 102 or 106) calculates the available padding bits (e.g., 412). Aprocessor (e.g., 200 or 300) may perform this calculation.

In an ensuing decision step 1216, the transmitting device determines ifthe length of extension header is greater than the available paddingbits. The transmitting device may use a processor (e.g., 200 or 300) ora variety of other modules to make this determination. If the answer tothe inquiry is no, the method 1200 proceeds to the step 1212, which wasdescribed above.

If the answer to the inquiry in the decision step 1216 is yes, themethod 1200 proceeds to the decision step 1218, in which thetransmitting device determines if extension headers are beingfragmented. A processor (e.g., 200 or 300) may perform thisdetermination using a memory (e.g., 204 or 304). The process offragmenting one or more extension headers was described above withreference to FIG. 9. If the answer to the inquiry is no, the method 1200proceeds to the decision step 1220, to be described in detail laterbelow.

If the answer to the inquiry in the decision step 1218 is yes, themethod 1200 proceeds to the step 1222, in which the transmitting deviceputs the fragment of extension header into the frame. A processor (e.g.,200 or 300) and/or message formatter (e.g., 202 or 302) could put thefragment of extension header into the frame. The fragment of extensionheader could be inserted into the pad bits 412 of the PSDU 406, as wasdescribed above with reference to FIG. 7.

After completing the step 1222, the method 1200 proceeds to the ensuingstep 1224, in which the transmitting device may put FCS (e.g., 1002),tail bits (e.g., 1004) and pads bits (e.g., 1006) for the one or moreextension headers into the frame. In another embodiment, the FCS, tailbits, and/or pad bits for extension headers may not be put into theframe. For example, if the method 1200 used the header extensionstructure illustrated in FIG. 8, the FCS and tail bits would not beinserted. Furthermore, a processor (e.g., 200 or 300) and/or a messageformatter (e.g., 202 or 302) could put the FCS, tail bits, and pad bitsinto the frame. Additionally, the extension headers and hence the FCS,tail bits, and pad bits of extension headers could be put in the frameat a variety of locations. For example, with reference to FIG. 7, theextension headers along with the FCS, tail bits, and pad bits of theextension headers could be inserted into the pad bits 412 of the PSDU406. In another embodiment, the FCS, tail bits, and pad bits of theextension headers may be put in the payload of the PSDU 406 between thePLCP header 404 and the actual frame payload 410, using a daisy chainstructure, as described above with reference to FIG. 6.

After the step 1224 is completed, the method 1200 proceeds to theensuing step 1226, in which the transmitting device puts the framepayload including any extension headers, into the PPDU or framestructure (e.g., 400). In embodiment, the transmitting device may putFCS, tail bits, and pad bits for the PSDU into the PPDU and/or framestructure (e.g., 400). The frame payload may be put into the framestructure using a processor (e.g., 200 or 300) and/or by a messageformatter (e.g., 202 or 302). After completing the step 1224, the method1200 proceeds to an ending step 1228.

In the decision step 1220, the transmitting device determines if atleast one extension header is present in the frame. A processor (e.g.,200 or 300) may perform this determination. If the answer to thedecision step is yes, the method 1200 proceeds to the step 1224, whichwas described above. If the answer to the decision step is no, themethod 1200 proceeds to the step 1226, which was also described above.

In one embodiment, shorter medium access durations may be achieved inthe communication system 200. As discussed above, in one embodiment, ifA≦P the PSDU duration may be extended, where A corresponds to the totallength of the extension header elements desired to be inserted and Pcorresponds to the number of information bits in 6 OFDM symbols at agiven PHY data rate. For example, there may be three scenarios fortransmitting extension headers: Case A where the extension header istransmitted without an FCS, Case B where the extension header istransmitted with separate FCS and tail bits, and Case C where theextension header is transmitted as a separate PSDU. T refers to themedium access duration for extension headers. In this embodiment,T_(6SYM) refers to the duration of 6 OFDM symbols which may be 1.875 us.For Cases A and B, the expected medium access duration may be shown bythe equation E(T)=(N+q)*T_(6SYM), where N is the number of additional 6OFDM symbol durations that will be needed to transmit the extensionheader and q is the probability that an additional 6 OFDM symbolduration will be needed.

For Case C, because the extension header is transmitted in the payloadof a separate PSDU, a short inter-frame space (SIFS) may be used. Inaddition, the separate PSDU may also use a separate preamble and aseparate header. Thus, the time to transmit the extension header in aseparate PSDU may be shown by the equationT=T_(SIPS)+T_(PREAMBLE)+T_(PLCPHEADER)+T_(PAYLOAD), where T_(SIFS)refers to the time for the SIFS, T_(PREAMBLE) refers to the time totransmit the preamble, T_(PLCPHEADER) refers to the time to transmit thePLCP header, and T_(PAYLOAD) refers to the time to transmit the payload.In this embodiment, T_(SIFS)=10 us, T_(PREAMBLE)=9.375 us, andT_(PLCPHEADER)=3.75 us. Also, T_(PAYLOAD)=(N+z)*T_(6SYM), where z is 0if A mod P is 0, and 1 otherwise (A is the total length of the extensionheader and P is the number of information bits in 6 OFDM symbols for agiven data rate PHY rate).

The difference between the expected medium access durations for Cases Band C may be shown by the equationΔT=T_(SIFS)+T_(PREAMBLE)+T_(PLCPHEADER)+(z−q)* T_(6SYM).

As shown above, the medium access durations for Cases A and B are lessthan the medium access duration for Case C. In Case C, extra overheadmay be incurred as a result of transmitting the extension header data inthe payload of a separate PSDU. However, in Cases A and B, the extensionheader data may fit within the padding bits or payload of a previouspacket. Thus, a separate PSDU may not be necessary resulting in ashorter medium access duration for Cases A and B. In one embodiment, themedium access durations for all cases may decrease as the data rate ofthe communication rate 100 increases. The absence of static overheadsand/or the efficient use of the padding area in the payload may decreasethe medium access duration (e.g., increase the efficiency) of thecommunication system 100.

It should be understood that any reference to an element herein using adesignation such as “first,” “second,” and so forth does not generallylimit the quantity or order of those elements. Rather, thesedesignations may be used herein as a convenient method of distinguishingbetween two or more elements or instances of an element. Thus, areference to first and second elements does not mean that only twoelements may be employed there or that the first element must precedethe second element in some manner. Also, unless stated otherwise a setof elements may comprise one or more elements. In addition, terminologyof the form “at least one of: A, B, or C” used in the description or theclaims means “A or B or C or any combination of these elements.”

The embodiments presented herein and other embodiments are furtherdescribed in greater detail in the attached Appendix. While thespecification describes particular examples of the present invention,those of ordinary skill may devise variations of the present inventionwithout departing from the inventive concept. For example, the teachingsherein refer to circuit-switched network elements but are equallyapplicable to packet-switched domain network elements.

Those skilled in the art will understand that information and signalsmay be represented using any of a variety of different technologies andtechniques. For example, data, instructions, commands, information,signals, bits, symbols, and chips that may be referenced throughout theabove description may be represented by voltages, currents,electromagnetic waves, magnetic fields or particles, optical fields orparticles, or any combination thereof.

Those skilled in the art will further appreciate that the variousillustrative logical blocks, modules, circuits, methods and algorithmsdescribed in connection with the examples disclosed herein may beimplemented as electronic hardware, computer software, or combinationsof both. To clearly illustrate this interchangeability of hardware andsoftware, various illustrative components, blocks, modules, circuits,methods and algorithms have been described above generally in terms oftheir functionality. Whether such functionality is implemented ashardware or software depends upon the particular application and designconstraints imposed on the overall system. Skilled artisans mayimplement the described functionality in varying ways for eachparticular application, but such implementation decisions should not beinterpreted as causing a departure from the scope of the presentinvention.

The various illustrative logical blocks, modules, and circuits describedin connection with the examples disclosed herein may be implemented orperformed with a general purpose processor, a digital signal processor(DSP), an application specific integrated circuit (ASIC), a fieldprogrammable gate array (FPGA) or other programmable logic device,discrete gate or transistor logic, discrete hardware components, or anycombination thereof designed to perform the functions described herein.A general-purpose processor may be a microprocessor, but in thealternative, the processor may be any conventional processor,controller, microcontroller, or state machine. A processor may also beimplemented as a combination of computing devices, e.g., a combinationof a DSP and a microprocessor, a plurality of microprocessors, one ormore microprocessors in conjunction with a DSP core, or any other suchconfiguration.

The methods or algorithms described in connection with the examplesdisclosed herein may be embodied directly in hardware, in a softwaremodule executed by a processor, or in a combination of the two. Asoftware module may reside in RAM memory, flash memory, ROM memory,EPROM memory, EEPROM memory, registers, hard disk, a removable disk, aCD-ROM, or any other form of storage medium known in the art. A storagemedium may be coupled to the processor such that the processor may readinformation from, and write information to, the storage medium. In thealternative, the storage medium may be integral to the processor. Theprocessor and the storage medium may reside in an ASIC.

In one or more exemplary embodiments, the functions described may beimplemented in hardware, software, firmware, or any combination thereof.If implemented in software, the functions may be stored on ortransmitted over as one or more instructions or code on acomputer-readable medium. Computer-readable media includes both computerstorage media and communication media including any medium thatfacilitates transfer of a computer program from one place to another. Astorage media may be any available media that may be accessed by acomputer. By way of example, and not limitation, such computer-readablemedia may comprise RAM, ROM, EEPROM, CD-ROM or other optical diskstorage, magnetic disk storage or other magnetic storage devices, or anyother medium that may be used to store desired program code in the formof instructions or data structures and that may be accessed by acomputer. Also, a connection may be used to transmit and/or receivecomputer-readable medium. For example, the software may be transmittedfrom a website, server, or other remote source using a coaxial cable,fiber optic cable, twisted pair, digital subscriber line (DSL), orwireless technologies such as infrared, radio, and microwave. Disk anddisc, as used herein, includes compact disc (CD), laser disc, opticaldisc, digital versatile disc (DVD), floppy disk and blu-ray disc wheredisks usually reproduce data magnetically, while discs reproduce dataoptically with lasers. Combinations of the above should also be includedwithin the scope of computer-readable media.

The previous description of the disclosed examples is provided to enableany person skilled in the art to make or use the present invention.Various modifications to these examples will be readily apparent tothose skilled in the art, and the generic principles defined herein maybe applied to other examples without departing from the spirit or scopeof the invention. Thus, the present invention is not intended to belimited to the examples shown herein but is to be accorded the widestscope consistent with the principles and novel features disclosedherein.

What is claimed is:
 1. A communication device for transmitting at leasta first packet in a wireless communication system, wherein the firstpacket comprises a header field, a payload field, and a padding field,the communication device comprising: a memory configured to store afirst extension header; a message formatter in communication with thememory, the message formatter configured to: indicate in the headerfield the presence of the first extension header, and insert at leastone portion of the first extension header in at least one of the payloadfield and the padding field of the first packet, the payload field andthe padding field being separate from the header field.
 2. Thecommunication device of claim 1, wherein the memory is furtherconfigured to store a second extension header, and wherein the messageformatter is further configured to indicate in a field of the firstextension header the presence of the second extension header, and insertat least one portion of the second extension header in at least one ofthe payload field and the padding field of the first packet.
 3. Thecommunication device of claim 1, further comprising a processorconfigured to determine at least one bit that does not fit in theplurality of bits occupying the header field.
 4. The communicationdevice of claim 1, wherein the message formatter comprises at least oneof a general purpose processor, a digital signal processor, anapplication specific integrated circuit, a programmable logic device,discrete gate logic, transistor logic, and discrete hardware components.5. The communication device of claim 1, wherein the message formatter isfurther configured to insert the at least one portion of the firstextension header in a beginning portion of the payload field of thefirst packet.
 6. The communication device of claim 5, wherein themessage formatter is further configured to modify a length field of theheader field of the first packet based on, at least in part, the lengthof the at least one portion of the first extension header.
 7. Thecommunication device of claim 1, wherein the at least one portion of thefirst extension header inserted comprises a content field.
 8. Thecommunication device of claim 1, wherein the at least one portion of thefirst extension header inserted comprises a frame check sequence andtail bits.
 9. The communication device of claim 1, wherein the at leastone portion of the first extension header comprises a length fieldindicating the length of the at least one portion of the first extensionheader.
 10. The communication device of claim 1, wherein the messageformatter is further configured to insert the first extension header inthe padding field of the first packet if the length of the firstextension header is less than or equal to the length of the paddingfield of the first extension header.
 11. The communication device ofclaim 2, further comprising a transmitter configured to transmit thefirst packet and a second packet, wherein the second packet comprises aheader field, a payload field, and a padding field, and wherein thefirst extension header comprises a first portion and a second portion,and wherein the message formatter is further configured to insert thefirst portion in at least one of the payload field and the padding fieldof the first packet and the second portion in at least one of thepayload field and the padding field of the second packet, and whereinthe length of the first portion is less than or equal to the length ofthe padding field of the first packet.
 12. A communication device fortransmitting at least a first packet in a wireless communication system,wherein the first packet comprises a header field, a payload field, anda padding field, the communication device comprising: means for storinga first extension header; and means for indicating in the header fieldthe presence of the first extension header and inserting at least oneportion of the first extension header in at least one of the payloadfield and the padding field of the first packet, the payload field andthe padding field being separate from the header field, wherein theindicating and inserting means is in communication with the storingmeans.
 13. The communication device of claim 12, wherein the means forstoring is further configured to store a second extension header, andwherein the means for indicating is further configured to indicate in afield of the first extension header the presence of the second extensionheader, and insert at least one portion of the second extension headerin at least one of the payload field and the padding field of the firstpacket.
 14. The communication device of claim 12, further comprisingmeans for determining is further configured to determine at least onebit that does not fit in the plurality of bits occupying the headerfield.
 15. The communication device of claim 12, wherein the means forindicating comprises at least one of a general purpose processor, adigital signal processor, an application specific integrated circuit, aprogrammable logic device, discrete gate logic, transistor logic, anddiscrete hardware components.
 16. The communication device of claim 12,wherein the means for indicating is further configured to insert the atleast one portion of the first extension header in a beginning portionof the payload field of the first packet.
 17. The communication deviceof claim 16, wherein the means for indicating is further configured tomodify a length field of the header field of the first packet based on,at least in part, the length of the at least one portion of the firstextension header.
 18. The communication device of claim 12, wherein theat least one portion of the first extension header inserted comprises acontent field.
 19. The communication device of claim 12, wherein the atleast one portion of the first extension header inserted comprises aframe check sequence and tail bits.
 20. The communication device ofclaim 12, wherein the at least one portion of the first extension headercomprises a length field indicating the length of the at least oneportion of the first extension header.
 21. The communication device ofclaim 12, wherein the means for indicating is further configured toinsert the first extension header in the padding field of the firstpacket if the length of the first extension header is less than or equalto the length of the padding field of the first extension header.
 22. Amethod of communicating at least a first packet in a wirelesscommunication system, wherein the first packet comprises a header field,a payload field, and a padding field, the method comprising: storing afirst extension header; and indicating in the header field of the firstpacket the presence of the first extension header and inserting at leastone portion of the first extension header in at least one of the payloadfield and the padding field of the first packet, the payload field andthe padding field being separate from the header field.
 23. The methodof claim 22, further comprising storing a second extension header, andwherein the means for indicating is further configured to indicate in afield of the first extension header the presence of the second extensionheader, and insert at least one portion of the second extension headerin at least one of the payload field and the padding field of the firstpacket.
 24. The method of claim 22, further comprising determining atleast one bit that does not fit in a plurality of bits occupying theheader field.
 25. The method of claim 22, further comprising insertingthe at least one portion of the first extension header in a beginningportion of the payload field of the first packet.
 26. The method ofclaim 25, further comprising modifying a length field of the headerfield of the first packet based on, at least in part, the length of theat least one portion of the first extension header.
 27. The method ofclaim 22, wherein the at least one portion of the first extension headerinserted comprises a content field.
 28. The method of claim 22, whereinthe at least one portion of the first extension header insertedcomprises a frame check sequence and tail bits.
 29. The method of claim22, wherein the at least one portion of the first extension headercomprises a length field indicating the length of the at least oneportion of the first extension header.
 30. The method of claim 22,further comprising inserting the first extension header in the paddingfield of the first packet if the length of the first extension header isless than or equal to the length of the padding field of the firstextension header.
 31. A computer readable product, comprising: anon-transitory computer-readable storage medium encoded withinstructions that, when executed by a computer, cause the computer to:store a first extension header of a first packet comprising a headerfield, a payload field, and a padding field; and indicate in the headerfield of the first packet the presence of the first extension header andinsert at least one portion of the first extension header in at leastone of the payload field and the padding field of the first packet, thepayload field and the padding field being separate from the headerfield.
 32. The computer readable product of claim 31, wherein theinstructions, when executed by the computer, further cause the computerto store a second extension header, and to indicate in a field of thefirst extension header the presence of the second extension header, andto insert at least one portion of the second extension header in atleast one of the payload field and the padding field of the firstpacket.
 33. The computer readable product of claim 31, wherein theinstructions, when executed by the computer, further cause the computerto determine at least one bit that does not fit in a plurality of bitsoccupying the header field.
 34. The computer readable product of claim31, wherein the instructions, when executed by the computer, furthercause the computer to insert the at least one portion of the firstextension header in a beginning portion of the payload field of thefirst packet.
 35. The computer readable product of claim 31, wherein theinstructions, when executed by the computer, further cause the computerto modify a length field of the header field of the first packet basedon, at least in part, the length of the at least one portion of thefirst extension header.
 36. The computer readable product of claim 31,wherein the at least one portion of the first extension header insertedcomprises a content field.
 37. The computer readable product of claim31, wherein the at least one portion of the first extension headerinserted comprises a frame check sequence and tail bits.
 38. Thecomputer readable product of claim 31, wherein the at least one portionof the first extension header comprises a length field indicating thelength of the at least one portion of the first extension header. 39.The computer readable product of claim 31, wherein the instructions,when executed by the computer, further cause the computer to insert thefirst extension header in the padding field of the first packet if thelength of the first extension header is less than or equal to the lengthof the padding field of the first extension header.